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This Appeal Brief is submitted in support of the Notice of Appeal filed July 18, 2005, in 
response to the Examiner reopening prosecution in the Office Action dated April 12, 2006, and 
in further response to the Examiner reopening prosecution in the Office Action dated December 
19, 2006, and in further response to the Examiner reopening prosecution in the Office Action 
dated July 23, 2007, and in further response to the Examiner reopening prosecution in the Office 
Action dated April 17, 2008, wherein Appellants appeal from the Examiner's rejection of claims 
1-27. 
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Sir: 



I. REAL PARTY IN INTEREST 

This application is assigned to IBM Corporation by assignment recorded on August 22, 
2000, at Reel 01 1 152, Frame 0250. 
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II. RELATED APPEALS AND INTERFERENCES 

Appellants are unaware of any related appeals and interferences. 

III. STATUS OF CLAIMS 

Claims 1-27 are pending and seven-times rejected in this Application. It is from the 
multiple rejections of claims 1-27 that this Appeal is taken. 

IV. STATUS OF AMENDMENTS 

The claims have not been amended subsequent to the imposition of the Final Office 
Action dated March 18, 2005 (hereinafter the Third Office Action), or the reopening of 
prosecution by the Examiner in the Office Action dated April 12, 2006 (hereinafter the Fourth 
Office Action), or the reopening of prosecution by the Examiner in the Office Action dated 
December 19, 2006 (hereinafter the Fifth Office Action), or the reopening of prosecution by the 
Examiner in the Office Action dated July 23, 2007 (hereinafter the Sixth Office Action), or the 
reopening of prosecution by the Examiner in the Office Action dated April 17, 2008 (hereinafter 
the Seventh Office Action). Although a Response was submitted with respect to the Third Office 
Action pursuant to the provisions of 37 C.F.R. § 1.116 on May 19, 2005, this Response did not 
make any changes or additions to the claims. 

V. SUMMARY OF CLAIMED SUBJECT MATTER 

Referring to claims 1 and 12 and Figures 1 and 4 A, 4B of Appellants' specification, a 
method of establishing a persistent relationship between an end user device 101, 103 and a server 
109 where the server 109 is one of a plurality of servers 109 managed by a dispatcher 107 and 
the end user device 101, 103 accesses the server 109 using a uniform resource locator (URL) is 
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disclosed. In step 401, a request for information from the end user device is received at the 
dispatcher 107, and the dispatcher 107 determines which of a plurality of servers 109 to select 
for satisfying the request (page 10, lines 12-15). In step 403, a token 235 is created at the 
selected server 109, and the token 235 includes at least an identifier 207 for the selected server 
109, a date/time stamp 209, and a key 211. The key 211 accesses a server-side storage area for 
information regarding the persistent relationship and the end user device (page 10, lines 16-25). 
In step 437, the token 235 is inserted into the URL (page 12, lines 1-9). In step 439, a response, 
with the token 235 inserted into the URL, is sent by the selected server 109 to the client device 
101, 103. 

Referring to independent claims 7 and 18 and Figures 1 and 3 of Appellants' 
specification, a method of routing a request by an end user device 101, 103 to a particular one of 
a plurality of redundant servers 109 residing behind a network dispatching mechanism 107 is 
disclosed. In step 301, a request for information indicated by a uniform resource locator (URL) 
is received at the network dispatching mechanism 107 (page 12, line 16). In step 303, the 
network dispatching mechanism 107 determines if the URL contains a valid routing token 235 
(page 12, lines 17-18). In step 311, a determination is made at the network dispatching 
mechanism 107 as to whether the session binding indicated by the routing token 235 is old (page 
12, lines 21-22). In step 313, if the routing token 235 is not old, the network dispatching 
mechanism 107, forwards the request, including the URL, to the particular server 109 indicated 
by the valid routing token 235 (page 12, lines 26-27). 

The valid routing information from the URL is removed by the particular server 109 
(page 13, line 6). The particular server 109 stores the routing information removed from the 
valid routing token 235, and the valid routing information can be accessed subsequently by an 
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outbound data stream filter during the processing of an outbound reply related to the request 
(page 13, lines 6-7). The particular server 109 accesses a server-side storage location where 
session information regarding a session between the particular server 109 and the end user device 
101, 103 is stored, and the accessed session information is inserted into the request (page 9, lines 
11-5). 

Referring to independent claims 10 and 20 and Figure 4B, a method of sending 
information to a requesting end user 101, 103 from an application over a session wherein the 
application resides at one of a plurality of redundant servers 109 residing behind a network 
dispatcher 107 is disclosed. In step 421, response information including a URL (uniform 
resource locator) is received from the application (page 11, lines 8-10). In step 423, a 
determination is made if a server-side key cookie has been used for storing session information 
between the end user 101, 103 and the application (page 11, lines 10-14). In step 425, if server- 
side key cookie has been used for storing session information, a session key 211 from the key 
cookie is retrieved (page 11, line 14). In step 426, if a key cookie was not used for storing 
session information, a session key from a control block is retrieved. In step 427, all cookies are 
removed from the response information (page 10, lines 14-15). In step 429, the removed cookies 
are stored in a predetermined server-side storage area (page 11, lines 14-16). 

In step 431, the URL is updated to indicate the removal of the cookies (page 11, lines 20- 
27). In step 433, a sticky routing string is created (page 11, line 27 through page 12, line 1). In 
step 435, a date/time stamp in the sticky routing string is updated page 11, line 27 through page 
12, line 1). In step 437, the sticky routing string is inserted into the URL (page 12, lines 1-8). In 
step 439, the response information, including the URL, is transmitted to the end user 101.103 
(page 12, lines 8-9). 
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Referring to independent claim 22 and Figures 1-2 and 4A, 4B of Appellants' 
specification, a network dispatcher 107 for establishing a persistent relationship between an end 
user device 101, 103 and a server 109 where the server 109 is one of a plurality of servers 109 
managed by the network dispatcher 107 is disclosed. Means are included for receiving a request 
for information from the end user device at the dispatcher, and means are included to determine 
which of a plurality of servers 109 to select for satisfying the request (page 10, lines 12-15). 
Means are included for creating the token 235, which includes at least an identifier 207 for the 
selected server 109, a date/time stamp 209, and a key 211. The key 211 accesses a server-side 
storage area for information regarding the persistent relationship and the end user device 101, 
103 (page 10, lines 16-25). Means are included for inserting the token 235 into the URL (page 
12, lines 1-9), and means are included for sending, by the selected server 109, a response, with 
the token 235 inserted into the URL, to the client device 101, 103. 

VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

1. Claims 12-21 were rejected under 35 U.S.C. § 101; 

2. Claim 9 was rejected under the second paragraph of 35 U.S.C. § 1 12; 

3. Claims 7-8 and 18-19 were rejected under 35 U.S.C. § 103 for obviousness based 
upon Kunzelman et al, U.S. Patent No. 6,041,357 (hereinafter Kunzelman), in view of Masters 
(U.S. Patent No. 6,374,300); 

4. Claims 1-6, 9, 12-16, and 22-27 were rejected under 35 U.S.C. § 103 for obviousness 
based upon Brendel, U.S. Patent No. 6,772,333, in view of Masters; and 

5. Claims 10-11, 17, and 20-21 were rejected under 35 U.S.C. § 103 for obviousness 
based upon Gupta et al, U.S. Patent No. 6,763,468 in view of Masters. 
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VII. ARGUMENT 

Although an objection is not appealable, Appellants wish to address the Examiner's 
objection to the specification since, based upon prior experience, the Examiner is more likely to 
reopen prosecution than this present Appeal is to reach the Honorable Board. In the paragraph 
spanning pages 2 and 3 of the Seventh Office Action, the Examiner asserted that page 12 of 
Appellants' specification includes browser-executable code. Appellants respectfully disagree. 
The link identified by the examiner is a broken link (i.e., a link that a browser will not execute). 
Specifically, a space exists between the two slashes (i.e., "http:/ /" instead of "http://"). The 
addition of this space causes the link to be broken and not executable by a browser. Appellants, 
therefore, respectfully solicit withdrawal of the imposed objection to the specification. 

The Rejection of Claims 12-21 under 35 U.S.C. § 101 

For convenience of the Honorable Board in addressing the rejections, claims 13-21 stand 
or fall together with independent claim 12. 

On page 3 of the Seventh Office Action, the Examiner asserted the following regarding 
claims 12-21: 

Claims 12 - 21 recite "A computer program product" and "computer readable code 
means" which are directed to software, per se, and are thus non-statutory unless computer- 
implemented on a computer-readable medium. 

As noted by the Examiner, claim 12 recites a computer program product having computer 
readable code means (i.e., a computer readable medium). A computer usable/readable medium 
is an article of manufacture and, thus, is statutory. In this regard, reference is made to M.P.E.P. § 
2106.01, which states: 
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When functional descriptive material is recorded on some computer-readable medium, it becomes 
structurally and functionally interrelated to the medium and will be statutory in most cases since 
use of technology permits the function of the descriptive material to be realized. 

Thus, the claimed invention, as recited in claim 12, is directed to statutory subject matter. 
Appellants, therefore, respectfully submit that the Examiner has failed to establish a proper rejection 
under 35 U.S.C. § 101 for the reasons set forth above. 

Despite these arguments being presented in the Fourth Appeal Brief dated October 23, 2007 
(hereinafter the Fourth Appeal Brief), the Examiner did not address these arguments in the Seventh 
Office Action. Moreover, Appellants note that the Federal Circuit has held that claims can recite 
non- statutory subject matter so long as the claimed invention, as a whole, produces a useful, 
concrete, and tangible result. Therefore, even if the claims could cover non- statutory subject 
matter, the claimed invention, as a whole, could still meet the requirements of 35 U.S.C. § 101. 
The Examiner, however, has not explained why the claimed invention, as a whole, does not 
produce a useful, concrete, and tangible result. Therefore, the Examiner has failed to establish a 
prima facie rejection under 35 U.S.C. § 101. 

The Rejection of Claim 9 under the Second Paragraph of 35 U.S.C. § 112 

For convenience of the Honorable Board in addressing the rejections, claim 9 stands or 
falls alone. 

On page 3 of the Seventh Office Action, the Examiner asserted the following: 

Claim 9 recites the limitation "all filtering" in line 1 of the claim. There is insufficient 
antecedent basis for this limitation. 

Appellants disagree. The term "all filtering" does not require antecedent basis since the term 
itself introduces the concept of filtering. Appellants, therefore, respectfully submit that the 
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Examiner has failed to establish a proper rejection under the second paragraph of 35 U.S.C. § 1 12. 
Despite these arguments being presented in the Fourth Appeal Brief, the Examiner did not address 
these arguments in the Seventh Office Action. 

The Rejection of Claims 7-8 and 18-19 under 35 U.S.C. § 103 for Obviousness 

BASED UPON KUNZELMAN IN VIEW OF MASTERS 

For convenience of the Honorable Board in addressing the rejections, claims 8 and 18-19 
stand or fall together with independent claim 7. 

As is evident from Appellants' previously-presented comments during prosecution of the 
present Application and from Appellants' comments below, there are questions as to how the 
limitations in the claims correspond to features in the applied prior art. In this regard, reference 
is made to M.P.E.P. § 1207.02, entitled "Contents of Examiner's Answer." Specifically, the 
following is stated: 

(A) CONTENT REQUIREMENTS FOR EXAME^ER'S ANSWER. The examiner's 
answer is required to include , under appropriate headings, in the order indicated, the following 
items: 

(9)(e) For each rejection under 35 U.S.C. 102 or 103 where there are questions 
as to how limitations in the claims correspond to features in the prior art even after the 
examiner complies with the requirements of paragraphs (c) and (d) of this section, the 
examiner must compare at least one of the rejected claims feature by feature with the 
prior art relied on in the rejection. The comparison must align the language of the claim 
side-by-side with a reference to the specific page, line number, drawing reference 
number, and quotation from the prior art, as appropriate, (emphasis added) 

Therefore, if the Examiner is to maintain the present rejections and intends to file an Examiner's 

Answer, the Examiner is required to include the aforementioned section in the Examiner's 

Answer. 
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"In rejecting claims under 35 U.S.C. § 103, the examiner bears the initial burden of 
presenting a prima facie case of obviousness."^ The legal conclusion of obviousness is based on 
underlying findings of fact including the scope and content of the prior art, the differences 
between the prior art and the claims at issue, and the level of ordinary skill in the pertinent arts. 
"Secondary considerations such as commercial success, long felt but unsolved needs, failure of 
others, etc., might be utilized to give light to the circumstances surrounding the origin of the 
subject matter sought to be patented."^ Therefore, to properly make a finding of obviousness, a 
comparison between the applied prior art and the claims at issue must be made to ascertain the 
differences between what is being claimed and the teachings of the applied prior art. Moreover, 
before making a proper comparison between the claimed invention and the prior art, the 
language of the claims must first be properly construed."^ This burden has not been met. 

At the outset. Appellants note that the Examiner is inconsistent in asserting what 
Kunzelman does or does not teach. On page 4 of the Seventh Office Action, the Examiner 
asserts that Kunzelman teaches the two limitations both starting "if said URL contains a valid 
routing token ...", but in the first full paragraph on page 5 of the Seventh Office Action, the 
Examiner asserts that Kunzelman fails to explicitly teach these limitations. 

Notwithstanding the Examiner's ambiguity as to what Kunzelman teaches or does not 

teach, the limitations that the Examiner is asserting that Kunzelman does not teach is the 

' InreRiickaert . 9 F.3d 1531, 1532 (Fed. Cir. 1993) (citing In re Qetiker. 977 F.2d 1443, 1445 (Fed. Cir. 1992)). 
^ KSR Int'l Co. V. TelefLex Inc.. 127 S.Ct 1727, 1734 (2007). 

^ Id. (quoting Graham v. John Deere Co. of Kansas City . 383 U.S. 1, 17-18 (1966)). 

See In re Paulsen . 30 F.3d 1475, 1479 (Fed. Cir. 1994); see also, Panduit Corp. v. Dennison Mfg. Co. . 810 F.2d 
1561, 1567-68 (Fed. Cir. 1987) (In making a patentability determination, analysis must begin with the question, 
"what is the invention claimed?" since "[c]laim interpretation, . . . will normally control the remainder of the 
decisional process"); see Gechter v. Davidson . 116 F.3d 1454, 1460 (Fed. Cir. 1997) (requiring explicit claim 
construction as to any terms in dispute). 
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following: 

receiving, at the network dispatching mechanism, a request for 
information indicated by a uniform resource locator (URL); 

determining, at the network dispatching mechanism, if said URL contains 
a valid routing token; 

if said URL contains a valid routing token, further determining, at the 
network dispatching mechanism, if a session binding indicated by said routing 
token is old; 

if said URL contains a valid routing token and said routing token is not 
old, forwarding, by said network dispatching mechanism, the request, including 
the URL, to the particular server indicated by said valid routing token. 

To teach these limitations, the Examiner asserted the following on page 5 of the Seventh Office 
Action: 

Yet, Masters teach receiving a request at the controller and determining if the URL contains a 
valid cookie for a specific server and routing the client's request to a selected server, 
wherein the cookie information includes data that identifies the selected server, a hash value and 
a time stamp (Figures 2-7, col. 2 lines 27-58, col. 5 line 33-col.6 line 31, col. 9 lines 4-34, 
col. 12 line 44-col . 13 line 47). (emphasis in original) 

In response, the Appellants submit that the Examiner's statement of the rejection fails to comply 
with 37 C.F.R. § 1.104(c), which reads: 

In rejecting claims for want of novelty or for obviousness, the examiner must cite the best 
references at his or her command. When a reference is complex or shows or describes inventions 
other than that claimed by the applicant, the particular part relied on must be designated as nearlv 
as practicable . The pertinence of each reference, if not apparent, must be clearly explained and 
each rejected claim specified, (emphasis added) 

In citing to eleven sheets of drawings (i.e.. Figs. 2-7) and nearly three columns of text, the 
Examiner has not designated the teachings in Masters "as nearly as practicable." Moreover, the 
Examiner has not clearly explained the pertinence of these cited passages. Thus, the Examiner 
has failed to properly set forth the facts as to the scope and content of the applied prior art. 



10 



Application No.: 09/557,708 

Notwithstanding the Examiner's invitation for Appellants to guess as to how the 
Examiner is construing the language of the claims and as to what specific teachings are being 
relied upon to teach the claimed limitations, Appellants note that the Examiner has not even 
alleged that Masters teaches all of the limitations that the Examiner has admitted that Kunzelman 
fails to teach. Specifically, the Examiner recognizes that Kunzelman does not teach the claimed 
"determining, at the network dispatching mechanism, if a session binding indicated by said 
routing token is old." The Examiner's statement as to the teachings of Masters found on page 5 
of the Seventh Office Action (and reproduced above) is completely silent as to these limitations. 
Thus, based upon these limitations alone, the Examiner has failed to establish a prima facie case 
of obviousness. 

Notwithstanding the Examiner's failure to establish a prima facie case of obviousness, the 
passages cited by the Examiner does not cure the Examiner's deficiency in clearly indicating 
where Masters teaches all of the limitations for which the Examiner is relying upon Masters to 
teach. The Examiner's cited passage of column 2, lines 27-58 refers to a time stamp that is 
generated by a node server. However, this passage is silent as to determining, at a network 
dispatching mechanism, if a session binding indicated by a routing token is old, as claimed. 

The Examiner second cited passage of column 5, line 33 through column 6, line 31 
indicates that a cookie (i.e., presumably corresponding to the claimed routing token) includes an 
expiration date (see column 5, line 63). However, absent from this passage is a teaching that the 
expiration date corresponds to the session binding and not just the cookie or that the 
determination (as to whether the session binding is old) occurs at the network dispatching 
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mechanism, as claimed. 

The Examiner's third cited passage of column 9, lines 4-34 refers to Fig. 3A of Masters. 
Upon reviewing this particular figure and cited passage. Appellants have been unable to discern 
any teachings regarding the aforementioned time stamp, expiration date of the cookie, or a 
determination that the session binding indicated by the routing token is old. 

The Examiner's last cited passage is column 12, line 44 through column 13, line 47. This 
passage refers to Figs. 6A-6B and 7A-7E of Masters. Upon reviewing these particular figures 
and cited passage. Appellants have been unable to discern any teachings regarding the 
aforementioned time stamp, expiration date of the cookie, or a determination that the session 
binding indicated by the routing token is old. 

Therefore, for the reasons stated above, the Examiner has failed to establish that Masters 
teaches all of the claimed limitations for which the Examiner is relying upon Masters to teach. 



Independent claim 7 recites the following: 

removing, by said particular server, said valid routing information from 
the URL. 

As claimed, "said particular server" refers to the server to which the request is routed from the 
network dispatching mechanism. To teach these limitations, on page 4 of the Seventh Office 
Action, the Examiner stated "parsing URL for session data" and cited column 6, lines 43-57 of 
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Kunzelman. For ease of reference, this passage is reproduced below: 

One application for the present invention is within the World Wide Web, where session 
tokens are encoded within URLs. When a session is to be migrated from a source server node to a 
target server node, a new URL will be generated for a session token. A client application will then 
make a request to the target server node using this URL. The target server node will then decode 
this session token, verify its authenticity (using public key cryptography) and obtain any necessary 
out-of-band session information before continuing with the request. Preferably, the session token 
is limited in size so that most browsers and HTTP handlers can correctly process the session token 
as a URL. A limit many browsers have for URLs is 1 kilobyte. If the session information is greater 
than the limit, some of the session information is sent as out-of-band data. 

This passage fails to identically disclose the above-reproduced claimed limitation for several 

reasons. First, there is no teaching of a particular server to which the request is routed from the 

network dispatching mechanism. Although this passage refers to the target server and the source 

server node, neither of these servers correspond to the claimed particular server. Moreover, the 

Examiner's assertion of "parsing URL for session data" corresponds to the claimed removing the 

valid routing information from the URL is misplaced. Removing and parsing are two very 

different acts. To "parse" is to identify an element from a group of elements. Parsing, however, 

does not require removing the element. Thus, the Examiner's analysis is flawed. Furthermore, 

regardless of the Examiner's characterization of the teachings in this passage, a review of this 

passage yields no teaching of removing, by any server, valid routing information from a URL. 

Thus, Kunzelman fails to teach all of the claimed limitations for which the Examiner is relying 

upon Kunzelman to teach. 

Although Appellants presented these arguments on 8 and 9 of the Fourth Appeal Brief, 
the Examiner did not respond to these arguments in the Seventh Office Action despite these 
arguments also applying to the Examiner's newly-presented rejection. 
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Independent claim 7 further recites the following: 

storing, by said particular server, said routing information removed from 
said valid routing token, where said valid routing information can be accessed 
subsequently by an outbound data stream filter during the processing of an 
outbound reply related to said request. 

To teach these limitations, on page 4 of the Seventh Office Action, the Examiner stated "caching 
and storing data for further access" and cited column 7, lines 59-67 of Kunzelman. For ease of 
reference, this passage is reproduced below: 

A querying server node wishing to obtain session information from a source server node 
would simply open a connection with the source server node, identify itself (the querying server 
node), get authenticated and then make a set of queries to obtain session data. The following is an 
example of the process where a querying server node (identified as server node 456 in this 
example) connects to a source server node (identified as server node 123) to request out-of-band 
data: 

Appellants are entirely unclear as to how this cited passage teaches any of the above- 
reproduced claim limitations. As noted before, the Examiner has failed to identify the claimed 
"said particular server," which in the limitations at issue, store the routing information and the 
routing information has been removed from the valid routing token. This cited passage is also 
unclear as to what constitutes the claimed "an outbound data stream filter during the processing 
of an outbound reply related to said request." Thus, Kunzelman further fails to teach all of the 
claimed limitations for which the Examiner is relying upon Kunzelman to teach. Although 
Appellants presented these arguments on page 9 and 10 of the Fourth Appeal Brief, the Examiner 
did not respond to these arguments in the Seventh Office Action despite these arguments also 
applying to the Examiner's newly-presented rejection. 
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Regarding the claimed "accessing ..." and "inserting ..." steps, the Examiner's cited 
passages are again unclear as to what constitutes the claimed "said particular server." Moreover, 
Appellants are unclear as to what, exactly, constitutes the claimed "server-side storage location." 
Therefore, for the reasons stated above, the Examiner has failed to establish that Kunzelman 
teaches all of the claimed limitations for which the Examiner is relying upon Kunzelman to 
teach. Yet again, although Appellants presented these arguments on page 10 of the Fourth 
Appeal Brief, the Examiner did not respond to these arguments in the Seventh Office Action 
despite these arguments also applying to the Examiner's newly-presented rejection. 

The Rejection of Claims 1-6, 9, 12-16, and 22-27 under 35 U.S.C. $ 103 for 

Obviousness based upon Brendel in view of Masters 

For convenience of the Honorable Board in addressing the rejections, claims 2-6, 9, 12- 
16, and 22-27 stand or fall together with independent claim 1. 

Independent claim 1 recites, in part, the following limitations: 

creating, at the selected server, a token comprising at least an identifier for 
the selected server, a date/time stamp, and a key, said key for accessing a server- 
side storage area for information regarding the persistent relationship and the end 
user device. 

Thus, as claimed, the token includes: (i) an identifier for the selected server, (ii) a date/time 
stamp, and (iii) a key. Also, the key is used for accessing a server-side storage area for 
information regarding the persistent relationship and the end user device. 

In the paragraph spanning pages 6 and 7 of the Seventh Office Action, the Examiner 
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asserted the following regarding this limitation: 

Although Brendel teaches embedding the SSL component into a webpage (col. 12 lines 
30-62), Brendel fails to explicitly teach a token comprising at least an identifier for the selected 
server, a date/time stamp, and a key, said key for accessing a server-side storage area for 
information regarding the persistent relationship at the end user device and inserting the token into 
the URL. Yet, Masters teach receiving a request at the controller and determining if the 
URL contains a valid cookie for a specific server and routing the client's request to a selected 
server, wherein the cookie information includes data that identifies the selected server, a hash 
value and a timestamp (Figures 2-7, col. 2 lines 27-58, col. 5 line 33-col.6 line 31, col. 9 
lines 4-34, col. 12 line 44-col 13 line 47). (emphasis in original) 

Appellants respectfully disagree with the Examiner's analysis. The teachings in Masters relied 

upon by the Examiner do not teach a key that used for accessing a server-side storage area for 

information regarding the persistent relationship and the end user device. In this regard, 

Appellants incorporate herein, as also applying to the present rejection, the arguments previously 

presented above with regard to the Examiner's reliance about Kunzelman to identically disclose 

the limitations recited in claim 7. Masters teaches a cookie that varies little in scope from the 

SSL session ID described by Brendel and used to identify the assigned server. 



Regarding the asserted rationale to combine Brendel and Kunzelman, the Examiner 

asserted the following in the paragraph spanning pages 6 and 7 of the Sixth Office Action: 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to combine the teachings of Brendel with Masters by inserting a cookie into a URL in 
order for a server to associate a client's session with a particular URL and track/monitor the user's 
activity on a particular website — such tracking methods are well-known in the art. 

The Examiner's analysis is specious. As is very well known in the art, a SSL session ID, as 

taught by Brendel, is already capable of being used for tracking a user's activity on a particular 

website. Thus, one having ordinary skill in the art would not have been impelled to make the 

Examiner's proposed modification since to do so would address an issue already addressed by 

the Examiner's primary reference of Brendel.^ 



See the non-precedential opinion of Ex parte Rinkevich . Appeal 2007-13 17 ("we conclude that a person of 
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Appellants further note that the Examiner's rationale for modifying Brendel in view of 
Masters is substantially identical to the Examiner's asserted rationale for modifying Brendel in 
view of Kunzelman in the Sixth Office Action. As such, the arguments presented above are 
substantially identical to the arguments presented by Appellants in the Fourth Appeal Brief 
However, despite these arguments also applying to the Examiner's current rejection, the 
Examiner has failed to address these arguments. 

The Rejection of Claims 10-11, 17, and 20-21 under 35 U.S.C. § 103 for 

Obviousness based upon gupta in view of Masters 

For convenience of the Honorable Board in addressing the rejections, claims 17 and 22 
stand or fall with independent claim 1; and claims 11 and 20-21 stand or fall together with 
independent claim 10. 

With regard to independent claim 10 and the teachings of Gupta, the Examiner asserted 
the following on page 9 of the Fifth Office Action, on page 9 of the Sixth Office Action, and on 
page 9 of the Seventh Office Action: 

if a server-side key cookie has been used for storing session information, retrieving a 
session key from said key cookie (col. 12 lines 3-8 and 44-55 — retrieving access session 
cookies); 

if a key cookie was not used for storing session information, retrieving said session key 
from a control block (col. 12 lines 8-18); 

storing said removed cookies in a predetermined server-side storage area (col.6 lines 28- 
37, col. 12 lines 48-55, col.l3 lines 13-17 — cookies are stored and maintained at the 
server). 

The Examiner's cited passage of column 12, lines 3-8, 44-55 is silent with regard to retrieving a 

ordinary skill in the art having common sense at the time of the invention would not have reasonably looked to Wu 
to solve a problem aheady solved by Savill") (emphasis in original). 
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session key from a key cookie. The only discussion within these passages are with regard to a 
"cookie (or token)" and not as to a session key within the key cookie. As to the last passage 
reproduced above, Appellants note that the citation of column 6, lines 28-37 is not only silent as 
to storing removed cookies, this passage describes what Gupta considers to be prior art. 
Moreover, although the Examiner's cited passage of column 12, lines 48-55 describes storing a 
cookie, this passage is silent as to storing a cookie, which has been removed . 

Thus, Gupta fails to teach several of the above-identified additional limitation for which 
Gupta is being relied upon by the Examiner to teach. Therefore, for the reasons stated above, 
even if one having ordinary skill in the art were motivated to modify Gupta in view of Masters, 
the claimed invention would not result. 

In the Seventh Office Action, as compared to the Sixth Office Action, the Examiner is 
now relying up Masters to teach removing all cookies form said response information as well as 
the additional limitations identified by the Examiner in the paragraph spanning pages 9 and 10 of 
the Seventh Office Action. Specifically, the Examiner asserted the following on page 10 of the 
Sixth Office Action: 

However, Masters teach receiving a request at the controller and determining if the URL 
contains a valid cookie for a specific server and routing the client's request to a selected 
server, wherein the cookie information includes data that identifies the selected server, a hash 
value and a timestamp (Figures 2-7, col. 2 lines 27-58, col. 5 line 33-col.6 line 31, col. 9 
lines 4-34, col. 12 line 44-col 13 line 47). (emphasis in original) 

Appellants note that this assertion by the Examiner is nearly identical to the assertion made by 
the Examiner with regard to independent claim 1 (see page 7 of the Seventh Office Action) and 
also with regard to independent claim 7 (see page 5 of the Seventh Office Action). However, the 
limitations that Masters is being cited for varies from independent claim 10 to claim 7 to claim 1. 
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Thus, the Examiner has not even attempted to put forth any specific analysis as to the individual 
claims. Instead, the Examiner has lumped independent claims 1, 7, and 10 together without 
explaining how Masters teaches the specific limitations for which Masters is being relied upon to 
teach. 

Notwithstanding the Examiner's continued ambiguity with regard to how the applied 
prior art allegedly teaches the claimed limitations. Masters fails to teach the limitations for which 
the Examiner is relying upon Masters to teach. Absent from the Examiner's cited passages is a 
teaching that the URL is updated to indicate the removal of the cooking, as claimed. Other 
limitations may also be absent from the Examiner's cited passage in Masters. However, since the 
Examiner has not clearly indicated what specific teachings within Masters allegedly disclose the 
claimed limitations for which Masters is being used to teach. Appellants have refrained from 
engaging in further guessing as to how the Examiner intends to apply Masters in the present 
rejection. 

Conclusion 

Based upon the foregoing. Appellants respectfully submit that the Examiner's rejections 
under 35 U.S.C. §§ 101, 103 and 112 are not factually or legally viable. AppeUants, therefore, 
respectfully solicit the Honorable Board to reverse the Examiner's rejections under 35 U.S.C. §§ 
101, 103 and 112. 

To the extent necessary, a petition for an extension of time under 37 C.F.R. § 1.136 is 
hereby made. Please charge any shortage in fees due under 37 C.F.R. §§ 1.17, 41.20, and in 



19 



Application No.: 09/557,708 



connection with the filing of this paper, including extension of time fees, to Deposit Account 09- 
0461, and please credit any excess fees to such deposit account. 



Date: May 29, 2008 Respectfully submitted. 



/Scott D. Paul/ 

Scott D. Paul 
Registration No. 42,984 
Steven M. Greenberg 
Registration No. 44,725 
Phone: (561)922-3845 
CUSTOMER NUMBER 46320 
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VIII. CLAIMS APPENDIX 

1 . A method of establishing a persistent relationship between an end user device and a 
server where the server is one of a plurality of servers managed by a dispatcher and the end user 
device accesses the server using a uniform resource locator (URL), the method comprising the 
steps of 

receiving at the dispatcher, a request for information from the end user device; 
determining, by the dispatcher, which of the plurality of servers to select for satisfying 
the request; 

creating, at the selected server, a token comprising at least an identifier for the selected 
server, a date/time stamp, and a key, said key for accessing a server-side storage area for 
information regarding the persistent relationship and the end user device; 

inserting the token into the URL; and, 

sending, by the selected server to the client device, a response with the token inserted into 
the URL. 

2. A method as claimed in claim 1 wherein said token is encoded using a modified 
Base64 encoding. 

3. A method as claimed in claim 1 wherein said token has a checksum or hash 
verification field. 

4. A method as claimed in claim 3 wherein said hash is a SHA-1 hash computed over 
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said identifier for said selected server, said date/time stamp, and said key. 

5. A method as claimed in claim 3 wherein said checksum or hash is encoded using a 
modified Base64 encoding. 

6. A method as claimed in claim 1 wherein said information regarding said persistent 
relationship is stored as a cookie on said server. 

7. A method of routing a request by an end user device to a particular one of a plurality 
of redundant servers residing behind a network dispatching mechanism, said methods comprising 
the steps of: 

receiving, at the network dispatching mechanism, a request for information indicated by a 
uniform resource locator (URL); 

determining, at the network dispatching mechanism, if said URL contains a valid routing 

token; 

if said URL contains a valid routing token, further determining, at the network 
dispatching mechanism, if a session binding indicated by said routing token is old; 

if said URL contains a valid routing token and said routing token is not old, forwarding, 
by said network dispatching mechanism, the request, including the URL, to the particular server 
indicated by said valid routing token; 

removing, by said particular server, said valid routing information from the URL; 

storing, by said particular server, said routing information removed from said valid 
routing token, where said valid routing information can be accessed subsequently by an 
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outbound data stream filter during the processing of an outbound reply related to said request; 

accessing, by said particular server, a server-side storage location where session 
information regarding a session between the particular server and the end user device is stored; 
and, 

inserting, by said particular server, said accessed session information into said request. 

8. A method as claimed in claim 7 wherein additional filtering of the URL is done prior 
to the forwarding step. 

9. A method as claimed in claim 1 wherein all filtering is performed within the 
dispatcher. 

10. A method of sending information to a requesting end user from an application over a 
session wherein said application resides at one of a plurality of redundant servers residing behind 
a network dispatcher, said method comprising the steps of 

receiving response information from said application, said response information 
including a URL (uniform resource locator); 

determining if a server-side key cookie has been used for storing session information 
between said end user and said application; 

if a server-side key cookie has been used for storing session information, retrieving a 
session key from said key cookie; 

if a key cookie was not used for storing session information, retrieving said session key 
from a control block; 
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removing all cookies from said response information; 

storing said removed cookies in a predetermined server-side storage area; 

updating said URL to indicate the removal of said cookies; 

creating a sticky routing string; 

updating a date/time stamp in said sticky routing string; 
inserting said sticky routing string into said URL; and, 
transmitting said response information, including said URL to said end user. 

IL A method as claimed in claim 10 wherein, prior to said determining step, said 
response information is transmitted from said application through one or more filters. 

12. A computer program product having computer readable code means of establishing a 
persistent relationship between an end user device and a server where the server is one of a 
plurality of servers managed by a dispatcher and the end user device accesses the server using a 
uniform resource locator (URL), the computer program product comprising: 

computer readable code means of receiving at the dispatcher, a request for information 
from the end user device; 

computer readable code means of determining by the dispatcher, which of the plurality of 
servers to select for satisfying the request; 

computer readable code means of creating, at the selected server, a token comprising at 
least an identifier for the selected server, a data/time stamp, and a key, said key for accessing a 
server-side storage area for information regarding the persistent relationship and the end user 
device; 
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computer readable code means of inserting the token into the URL; and, 
computer readable code means of sending, by the selected server to the client device, a 
response with the token inserted into the URL. 

13. A computer program product as claimed in claim 12 wherein said token is encoded 
using a modified Base64 encoding. 

14. A computer program product as claimed in claim 12 wherein said token has a 
checksum or hash verification field. 

15. A computer program product as claimed in claim 14 wherein said hash is a SHA-1 
hash computed over said identifier for said selected server, said date/time stamp, and said key. 

16. A computer program product as claimed in claim 14 wherein said checksum or hash 
is encoded using a modified Base64 encoding. 

17. A computer program product as claimed in claim 12 wherein said information 
regarding said persistent relationship is stored as a cookie on said server. 

18. A computer program product having computer readable code means for routing a 
request by an end user device to a particular one of a plurality of redundant servers residing 
behind a network dispatching mechanism, said computer program product comprising: 

computer readable program code for receiving, at the network dispatching mechanism, a 
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request for information indicated by a uniform resource locator (URL); 

computer readable program code for determining, at the network dispatching mechanism, 
if said URL contains a valid routing token; 

if said URL contains a valid routing token, computer readable program code for further 
determining, at the network dispatching mechanism, if a session binding indicated by said 
routing token is old; 

if said URL contains a valid routing token and said routing token is not old, computer 
readable program code for forwarding, by said network dispatching mechanism, the request, 
including the URL, to the particular server indicated by said valid routing token; 

computer readable program code for removing, by said particular server, said valid 
routing information from the URL; 

computer readable program code for storing, by said particular server, said routing 
information removed from said valid routing token, where said valid routing information can be 
accessed subsequently by an outbound data stream fiher during the processing of an outbound 
reply related to said request; 

computer readable program code for accessing, by said particular server, a server-side 
storage location where session information regarding a session between the particular server and 
the end user device is stored; and, 

computer readable program code for inserting, by said particular server, said accessed 
session information into said request. 

19. The computer program product as claimed in claim 18 wherein additional filtering of 
the URL is done prior to the forwarding step. 
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20. A computer program product having computer readable code means of sending 
information to a requesting end user from an application over a session wherein said application 
resides at one of a plurality of redundant servers residing behind a network dispatcher, said 
computer program product comprising: 

computer readable programming means of receiving response information from said 
application, said response information including a URL (uniform resource locator); 

computer readable programming means of determining if a server-side key cookie has 
been used for storing session information between said end user and said application; 

if a server-side key cookie has been used for storing session information, computer 
readable programming means of retrieving a session key from said key cookie; 

if a key cookie was not used for storing session information, computer readable 
programming means of retrieving said session key from a control block; 

computer readable programming means of removing all cookies from said response 
information; 

computer readable programming means of storing said removed cookies in a 
predetermined server-side storage area; 

computer readable programming means of updating said URL to indicate the removal of 
said cookies; 

computer readable programming means of creating a sticky routing string; 
computer readable programming means of updating a date/time stamp in said sticky 
routing string; 

computer readable programming means of inserting said sticky routing string into said 
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URL; and, 

computer readable programming means of transmitting said response information, 
including said URL to said end user. 

21. A computer program product as claimed in claim 20 wherein, prior to said 
determining step, said response information is transmitted from said application through one or 
more filters. 

22. A network dispatcher for establishing a persistent relationship between an end user 
device and a server where the server is one of a plurality of servers managed by said network 
dispatcher comprising: 

means for receiving a request for information from said end user device, said request for 
information including a uniform resource locator (URL); 

means for determining which of the plurality of servers to select for satisfying said 
request for information; 

means for creating, at said selected server, a token comprising at least an identifier for the 
selected server, a date/time stamp, and a key, said key for accessing a server-side storage area for 
information regarding the persistent relationship and the end user device; 

means for inserting the token into the URL; and, 

means for sending, by the selected server, a response with the token inserted into the 
URL to the client device. 

23. A network dispatcher as claimed in claim 22 wherein said token is encoded using a 
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modified Base64 encoding. 



24. A network dispatcher as claimed in claim 22 wherein said token has a checksum or 
hash verification field. 

25. A network dispatcher as claimed in claim 24 wherein said hash is a SHA-1 has 
computed over said identifier for said selected server, said date/time stamp, and said key. 

26. A network dispatcher as claimed in claim 24 wherein said checksum or hash is 
encoded using a modified Base64 encoding. 

27. A network dispatcher as claimed in claim 22 wherein said information regarding the 
persistent relationship is stored as a cookie on said server. 
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IX. EVIDENCE APPENDIX 

No evidence submitted pursuant to 37 C.F.R. §§ 1.130, 1.131, or 1.132 of this title or of 
any other evidence entered by the Examiner has been relied upon by Appellants in this Appeal, 
and thus no evidence is attached hereto. 
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X. RELATED PROCEEDINGS APPENDIX 

Since Appellants are unaware of any related appeals and interferences, no decision 
rendered by a court or the Board is attached hereto. 
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